User interfaces allow the computer user to interact or communicate with the computer system. User interfaces are typically implemented with a display screen and a user-controlled entry device, such as a keyboard, mouse, microphone, light pen or the like. The display screen displays information and data to the user and the user uses the entry device to give commands and provide information to the computer system.
During recent years, more and more people have wanted and needed to use the power of the computer in their daily work. However, generally these users do not want to be required to know specific commands, operators, syntax rules, etc, and much work has been expended on developing user interfaces which alleviate the need for such levels of knowledge. The most common form of user interface nowadays is the so-called graphical user interface (or GUI). Typically, a GUI presents the user with windows and icons. Windows typically include a menu bar, a tool bar, and a client area. The client area may typically include a number of icons, which are small stylized representation of entities (applications, folders, etc) with which the user works.
To enable the user to invoke particular operations on the computer system, the user interface needs to provide selection mechanisms to the user. In a typical user interface environment, this may be achieved by defining `actions` which the user can select via `views` of those actions provided via the user interface. For the purposes of this application, an action can be defined as a user initiated event which invokes an operation. The `views` used to represent an action within the user interface may take a number of different forms, both visual and non-visual.
Typical examples of visual views used in GUIs would be a word or phrase on a menu bar (as illustrated in FIG. 5A where the `Print` action is selected from a word view), a graphical representation such as an icon or bitmap on a tool bar (as illustrated in FIG. 5B where the `Print` action is selected from a print bitmap view), or other visual controls that enable user selection or input. Examples of such other controls are a combination box control that allows font selection (as illustrated in FIG. 5C), or an entry field that allows the setting of a string property such as setting the name of a directory or setting a tool bar name (as illustrated in FIG. 5D). These controls could appear anywhere within the user interface including a tool bar or a window layout. Further examples of visual views are illustrated in FIG. 5E, where the print action is selectable from a context menu displayed by depressing the right mouse button whilst positioned over the window area, and in FIG. 5F where the print action is selectable from a push button view in a window layout.
Examples of non-visual views would be accelerator data such as `Ctrl+P` used to select a print action, speech pattern data used to determine whether a speech input has selected the action, or gesture data to determine whether an input gesture (such as a stroke of a pen on a tablet) is a selection of a particular action. For the purposes of the present application, all such mechanisms for selecting actions (whether visual or non-visual) will be referred to as `views`.
Currently, when developing applications, a significant amount of developer effort is required to provide the functionality required to enable the user to select actions. Additionally, there is a problem in achieving user interface and functional consistency between applications that display views of actions which are functionally perceived by the user as being the same.
One reason why enablement of these actions is so time consuming to the developer is that there are a number of different places within an application where the user can select the same action, since there may be many views of a particular action available for selection by the user in different places within the user interface. Obvious views on actions are those found within menu bars, tool bars and context menus. However, there are also, for example, many places within an application where the user is presented with a push button that opens a dialog or window. This `action` could quite easily be available from a menu bar or context menu in other circumstances.
Some actions open dialogs, like the file open dialog, and some actions do not, but still perform an operation, like the cut, copy and paste actions. The thing that binds these operations together is the fact that they are made available to the user from views of actions. An example of this is where a user can select a print option from a menu bar pull down, a tool bar button on a tool bar, an entry on a context menu, or for example a push button on a dialog. Essentially the same operation of opening a print dialog occurs, but the visual selection mechanisms are different to achieve the same result.
A second consideration which increases the amount of effort required by the developer is that there are a number of different input mechanisms that can be employed by the user to select the same action. The standard point and click mechanism of the mouse is well understood, and this would be the typical mechanism used to select visual views displayed via the GUI. However, a number of actions also have accelerator options that allow selection via a specific character on the keyboard (eg `P` for selecting the `Print` action). Further, speech enabled applications allow the user to speak commands, so that for example the user can say `Print` to open the print dialog, and if a pen gesture has been defined for opening a print dialog, pen enablement will add another view that may be available for the user to select the action.
Additionally, there are situations where small interface behaviors are so pervasive that the same piece of code is written repeatedly throughout an application. An example of this is when an application has a number of dialog type windows that allow the user to cancel out of the window without applying any changes. The visual representation of this function may, for example, be a `Cancel` push button, but usually there is also a keyboard mechanism to achieve the same result, for example selection of the `Esc` key. Traditionally the developer would have to code three things to achieve this function, namely: a) to provide a push button on a dialog; b) to add the escape accelerator to the accelerator table; and c) to provide the cancel procedure within the application code. These three stages would normally be repeated every time the escape function is needed for an individual window.
The application developer thus currently has to write a significant amount of code to cope with these different scenarios, and when new technology is introduced, e.g. speech, additional work is needed by the developer to make that new selection mechanism available to the user. Since there are a number of permutations for the developer to remember, there are times when certain selection mechanisms are not enabled within products. This leads to usability problems across products, where one application works one way, and another does not. Added to this, the various views on the same actions usually are constructed in a number of different ways, and once constructed have little to no user customisation capabilities.
From the above, it will be apparent that there is currently a lot of work for the developer to do in order to fully support the various views of actions, both visual and non-visual, that are required. It is an object of the present invention to provide a system and method which alleviates the above identified problems.